node syncing and weak subjectivity #312
Conversation
chirag-parmar
force-pushed
the
syncing
branch
2 times, most recently
from
d9fdc6e to
5d5d364
Compare
chirag-parmar
changed the title
|
|
||
| ## Background | ||
|
|
||
| Before the merge, a new node synced (configured for a "full sync") with the blockchain as described below: |
There was a problem hiding this comment.
First, you should explain there are different strategies for EL and CL sync. What you are describing here is a single strategy for EL sync which still works today, there is no before/after the Merge. There is snap sync, fast sync, pivot sync for EL. CL weak subjectivity worked even before the Merge. The only new post Merge sync strategy is optmistic sync
There was a problem hiding this comment.
This seems to be the main point of contention for everyone who has proof read the document. Everything mentioned in the comment above is true, but snap sync, fast sync and pivot sync are just optimizations over the definitive method of syncing. Moreover, every client team in the past and present has had varying definitions of the mentioned optimizations. Mentioning them will serve no (as far as my knowledge goes) extra relevant information when considering weak subjectivity and other changes in the syncing process seen between a PoW Ethereum and a PoS Ethereum. For this, I think I should remove the sidenote "configured for a full sync" to avoid any confusion.
Regarding the chronology, whether CL weak subjectivity worked before the merge or not is irrelevant in the context of the canonical chain, IMHO. The only reason for explicitly mentioning "Before the Merge" and "After the Merge" is for the Merge to serve as a vantage point that brought the change in consensus mechanisms and also its effect on the syncing process. I think I should rephrase it as "Before the canonical chain switched to POS".
Do you think this would resolve the contention?
There was a problem hiding this comment.
Yes I agree, no need to dive into specific strategies for EL but you should add context that there are variations of EL sync strategy, make a clear distinction between EL and CL here.
remove 'configured for a full sync'
What you describe below is the naive full sync strategy so it shouldn't be removed.
"Before the canonical chain switched to POS"
That is literally the same as saying 'before the Merge.' But it the same as today, EL syncs very same way you are describing. I would rephrase this to make it clear that this is how EL handles finality with PoW or PoS
There was a problem hiding this comment.
Ah I see what you mean now. I'll change this. Seems like I just needed a fresh perspective
|
|
||
| > ETH1 backfills headers but the verification of block bodies happens from genesis -> target. In ETH2, the verification itself happens from target -> genesis. The core of blockchain syncing is verification; without a verified syncing process, there is no point in syncing. Hence, the verification direction is usually considered the syncing direction. | ||
|
|
||
| The second difference lies in the anchor of trust in information. Since the history of the chain can be changed under certain conditions the sync target cannot be objectively verified i.e. we can never concretely prove its existence in the canonical chain. Hence, there is a significant amount of trust placed in the sync target and it remains subjective. Because of the trust involved, sync targets (named weak subjectivity checkpoints) are shared out-of-band since random peer connections in the p2p layer of Ethereum cannot be trusted. It is important to note that, only the sync target remains subjective, all other information obtained is objectively verified i.e. the chain is *weakly* subjective. |
There was a problem hiding this comment.
An article on week subjectivity should dive into finality and how it keeps the chain secure.
Btw there is a decent article on ethorg docs but I suppose this page should focus more on the node experience and client behavior under the hood https://ethereum.org/en/developers/docs/consensus-mechanisms/pos/weak-subjectivity/
There was a problem hiding this comment.
I think you nailed it on this one. That article indeed touched everything related to weak subjectivity, therefore, I also linked it in the footer. It is a little opaque and assumes context of subjectivity and objectivity in blockchain technology which is the gap I wanted to fill. Vitalik's blog on the matter is too abstract for EPS fellows to consume, I think.
I think I touched on how weak subjectivity keeps the chain secure(maybe I did not fully?) but I'm not sure what role it has in finality. Maybe I am missing information. Can you point me to the specific stuff, I think my brain is fogged out XD?
There was a problem hiding this comment.
A recent finalized block becomes a weak subjectivity checkpoint. It should be clear that by finalizing the chain Casper is basically providing weak subjectivity to sync
There was a problem hiding this comment.
Thanks for pointing this out, usually obvious information is missed out making it difficult for someone just starting with the tech to understand.
| ## Background | ||
|
|
||
| Before the merge, a new node synced (configured for a "full sync") with the blockchain as described below: | ||
| 1. *Query for the latest "final" block from other nodes in the network.* In ETH1, there was no finality as such, but reversing the "work" (Proof-of-work) of 6 blocks was considered difficult enough to call the 7th block from the head "final." |
There was a problem hiding this comment.
One more thing which repeats in the whole doc - you keep using 'ETH1' here which is wrong nomenclature. Please keep it as EL/CL client to be consistent with rest of the content
There was a problem hiding this comment.
Ah, really gotta change that habit. Thanks
TODO: